File Delivery over Unidirectional Transport (FLUTE) is an Internet Protocol (IP) based point-to-multipoint file transfer protocol. FLUTE provides congestion control and forward error correction functions for unidirectional transfer of multiple files and therefore ensures the reliability in transferring large-sized files in one direction.
In FLUTE, one file is carried in one transport object (TO). Every transport object has a transport object identifier (TOI) and multiple transport objects are transferred in one FLUTE session. According to FLUTE, the transport object with TOI=0 is used to transfer a file description table (FDT). The FDT describes information of the transport objects transferred by the current FLUTE session, including TOI, uniform resource locator (URL) of the file carried by a transport object, and file type. FIG. 1 shows the structure of transport objects in a FLUTE session in the conventional art. As shown in FIG. 1, three files are respectively packed and carried in three transport objects, where Flag is an end mark, Flag=0 means the file does not end and Flag=1 means the file ends; the FDT describes the TOI and URL information of the three transport objects.
At present, FLUTE is widely applied to various mobile video broadcasting systems. FIG. 2 shows a traditional procedure of a FLUTE session in a digital video broadcasting-handheld (DVB-H) system. As shown in FIG. 2, the procedure includes:
Step 201: A server sends to a terminal an electronic service guide (ESG) which carries file reception information including IP address, port number and file URL.
Step 202: The terminal accesses a FLUTE session according to the IP address and the port number of the file to be received. Here, the file to be received is the file that the terminal determines to receive according to the ESG.
Steps 203 and 204: The server retransmits the FDT repeatedly; the terminal receives the FDT and determines the TOI corresponding to the file to be received according to the FDT and the URL of the file.
Step 205: The terminal receives the corresponding transport object according to the TOI.
Now, the traditional procedure of a FLUTE session in a prior DVB-H system comes to an end.
FIG. 3 shows processing procedure at the server in the FLUTE session shown in FIG. 2. For easy description, FIG. 3 only shows the processing procedure at the server that is related to the FLUTE protocol without showing other procedures such as the processing procedure at the ESG server. In the procedure shown in FIG. 3, the server includes a content server and a FLUTE server, where the FLUTE server includes a receiving module, a transport content generating module, an FDT generating module and a transmitting module. The procedure includes the following steps:
Step 301: The content server sends transport contents to the receiving module of the FLUTE server; here the transport contents include a file and a URL of the file.
Step 302: The receiving module sends the received transport contents to the transport content generating module.
Step 303: The transport content generating module sends the URL of the file to the FDT generating module and requests a TOI required for transferring the file from the FDT generating module.
Steps 304-306: The FDT generating module assigns a TOI to the file according to the URL of the file and returns the assigned TOI to the transport content generating module, and generates an FDT according to the TOI and URL of the file and sends the generated FDT to the broadcasting network via the transmitting module.
Step 307: The transport content generating module packs the file in a corresponding transport object according to the TOI and sends the transport object to the broadcasting network via the transmitting module.
Now, the processing procedure at the server in a FLUTE session is complete.
Notification is a service provided over a mobile video broadcasting system, which sends a message to a terminal to notify a forthcoming event. The terminal may carry out appropriate processing according to the received notification message. Notification messages include but are not limited to: emergency events, system related notifications (like failure of a certain system function), events related to program contents (like information of program actors and actresses, awarded questions and answers, program forecast messages, and paid weather forecast information) and software update notifications.
FIG. 4 shows structure of a notification message in the conventional art. As shown in FIG. 4, a notification message includes two parts, which are related information and content. The related information includes parameter information related to the notification message, such as ID and version of the notification message; the content part includes text content, and image or audio/video file, where the text content further includes two parts: one is the text file content to be presented to the user and the other is auxiliary information related to the notification message, such as an IP address and a port number of the FLUTE session where the image and/or audio/video file resides and information about how to present the message to the user.
The prior broadcast (BCAST) protocol provides a method for transporting notification messages, as shown in FIG. 5.
First, the server sends the related information and content of a notification message over the User Datagram Protocol (UDP), and sends the image and/or audio/video file (usually referred to an attachment) by carrying it in a corresponding transport object according to the processing procedure at the server shown in FIG. 3.
Then, the terminal receives the UDP packet at the specified UDP address and port number and parses the text content in the UDP packet to obtain the IP address, the port number and TOI of the FLUTE session of the attachment.
Then the terminal accesses the FLUTE session in the method shown in FIG. 2 to receive the corresponding transport object, or attachment, and finally assembles the attachment content and the text content to a complete notification message and presents the message to the user.
The applicant, however, finds that in the method shown in FIG. 5, the terminal must first access the UDP protocol, and then access a FLUTE session, which means the terminal must access two IP addresses so as to receive a notification message. As a result, the procedure of the prior method is complex and it is slow for the terminal to obtain a complete notification message. Furthermore, because of the unreliability of transport over LDP, the reliability in transporting notification messages cannot be ensured.